[レポート]セキュリティ研究者を増強することでOSS系脆弱性を淘汰する – CODE BLUE 2022 #codeblue_jp

CODE BLUE 2022で行われた「セキュリティ研究者を増強することでOSS系脆弱性を淘汰する」というセッションのレポートです。

#CODE BLUE

#CODE BLUE 2022

#セキュリティ

臼田佳祐

2022.10.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

今回はCODE BLUE 2022で行われた以下のセッションのレポートです。

セキュリティ研究者を増強することでOSS系脆弱性を淘汰する

セキュリティ研究者が、何千ものオープンソースソフトウェア（OSS）プロジェクトに影響を与えるセキュリティ脆弱性に気づき、それら全てを同時に特定し、修正することができる世界を想像してみてほしい。次に、脆弱性があなたのプロダクション・コードに入り込み、数分後に、その修正をするためのプル・リクエストが自動的に送られてくる世界を想像してみてくほしい。比較的簡単な修正で済むはずのセキュリティ脆弱性を発見するために、毎年何十万時間という人手が費やされている。これらの脆弱性は、セクシーでもクールでも新しいものでもなく、何年も前からわかっていたものであり、どこにでもあるものだといえる。

GitHubのスケールとCodeQL（GitHubのコードクエリー言語）のようなツールは、何十万ものOSSプロジェクトに存在する脆弱性をスキャンすることを可能にするが、課題はトリアージ、レポート、修正をどのようにスケールするかという点だ。単に数千のバグレポートを自動生成するだけでは役に立たず、OSSプロジェクトのボランティア・メンテナーにはさらに負担がかかってしまう。理想的なのは、メンテナーに脆弱性の情報だけでなく、対処が容易なプルリクエストという形で修正方法を提供することだろう。

このような規模の問題に直面したとき、研究者の知識を活用してOSS全体の最も多くの脆弱性を修正する最も効率的な方法とは何だろうか。本講演では、拡張性の高いソリューションであるプルリクエストの自動一括生成について説明する。また、この技術を実際のOSSプロジェクトに適用した事例も紹介する。さらに、CodeQLやOpenRewrite（Netflixで開発され、現在はModerneが開発する保持型リファクタリングツール）などの技術を取り上げる予定だ。脆弱性について話すだけでなく、実際の大規模修正に共に取り組んでいきたい。

本件は、新しい「Dan Kaminsky Fellowship」のスポンサーにより提供している。このフェローシップは、世界をより良い（そしてより安全な）場所にするオープンソースの仕事に資金を提供することによって、ダン・カミンスキー氏の記憶と遺産を称えるために創設されたものである。

Presented by : ジョナサン・ライチュー - Jonathan Leitschuh

レポート

自己紹介
- ソフトウェアセキュリティの研究者
- Git Hub Star
注意書き
- Human Securityの支援を受けている
ネタバラシ
- Zip Slip
- 152のPR
どのようにここに至ったか
スタートはこの脆弱性
- kotolinのコードが入っていた
- コピペで入っていた
- Attacker in the Middleにさらされてしまう
- Mavenの中の脆弱性
- Dependenciesにある
- Artifact uploadにもある
- この脆弱性はJAVAの色んな所にある
- 業界全体に影響がある
- トラフィックはHTTPを利用しているのが25%もあった
どうやって解決するか
- HTTP Decommissioningとした
2020年
- トラフィックの20%がまだHTTPを使っていた
- 2020年1月15日
- ソフトウェアが壊れた
- しかし流血はとまった
他のリポジトリはどうか
- Maven Central
- JCenter
- Spring
- Gradle Plugin Portal
どうやってその他を修正すれば良いのか
- バルクPRを作ってみよう
- CodeQLのクエリを作った
- 10万のOSSプロジェクトを見つけることができる
最初のPRジェネレータ
- Pythonで実装
- 脆弱性のあるファイルをFixする
- XMLパーサでやるとターゲットが変わるのでRegexにした
- しかし問題がある
- http -> httpsに置き換えたPR
- 約40%が修正された
- 大規模にPRするソリューション
問題
- ADHD
- 脆弱性を追いかけて学ぶのが好き
- GitHubのコードサーチで脆弱性をどこにでも見つけられる
- 脆弱性リスト - ZipSlip
- 重要な脆弱性が何ページも続く
- あまりに多くの脆弱性を見つけてしまう
- 自動化が必要
- アラートを出すだけではなく自動化が必要
OpenRewriteの登場
- ASTを生成する
- ASTをソースコードに吐き出そうと構成がなくなる
- OpenReWriteはこれを維持する
- 新しいコードを生成できる
- タブやスペースなど学習する
- OpenRewrite ASTは構文を理解できる
- 新しいコードを追加して修正したいときの問題はシンプルでもASTが複雑になる
どんな脆弱性を修正できるか
- Temporary Directory Hijacking
  - Unixライクのシステムですべてのユーザーでシェアされている
  - どのユーザーでも変更できる
  - コードを紹介
  - Google -> StackOverflow
  - このコードはレースコンディションがある
  - ifでくくってもまだ脆弱
  - JAVA1.7での修正方法紹介
  - いろんなところで存在している
  - 64のPRを生成した
  - 脆弱な行を安全なコードに置き換えている
- Partial Path Traversal
  - 兄弟のディレクトリに同じ文字から始まるものがあればアクセスできる
    - /user/samと/user/samansaみたいな関係
    - getCanonicalPath()するとスラッシュがなくなる
    - Fixは正しいパスで比較する
    - どうやって修正するか
    - 簡単にはできない
    - プログラマはいろんなコードの書き方をする
  - 新しいアプローチが必要
    - データフローを確認
    - 追跡できる
    - データフローは偽陽性を防ぐ
- AWS Java SDK
  - getCanonicalPath()
  - 脆弱性のディスクロージャーのストーリーがある
  - まだこれから
Zip Slip
- Key-Valueペア
- Keyをアタッカーがコントロールできる
- パストラバーサルできる
- コンテンツを上書きできる
- Zip Slipは複雑
- 有効なFixはいろんな書き方がある
- Control Flow Analysisを導入して考える
- 脆弱か否かを判断する
- Control Flowのグラフを見てチェックが入っているか確認する
Pull Request Generation
- 1つ目の問題
  - GitHubを横断して作成するときの速度
  - 3つの処理
    - File IO
    - Git Operation
    - GitHub API
  - checkoutしてブランチ作成してフォークしてリネームしてPushしてPR作成
  - それぞれ1秒あける必要がある
  - sleepさせる
- どのようにすべてのリポジトリで修正できるか
- Moderne
  - 大規模にPRを作成できる
  - ユースケースの1つはSpringの最新を使いたい時
  - テストフレームワークもアップデートしないといけない
  - どのバージョンでテストフレームワークを利用しているかも重要
世界には7,000以上のプロジェクトがある
- どうやって見つけるか
- CodeQLを使う
統計
- HTTP Download of Dependenciesは40%マージされた
- CVE-2019-16303は2.3%
ベストプラクティス
- PRの一括修正について
- メッセージングが大事
- すべてのソフトウェアの問題は人の問題
- デベロッパーやメンテナーは人を好む
- なぜこれをやっているか実際の人としてコミュニケーションすること
- なぜコミットを採用しないといけないか入れる
- GPGコミットサインすること
- SECOM
- 個人のGitHubアカウントを使うことは問題がある
- 怒ったユニコーンを見たことある？
- 会社やBotよりひとからの連絡のほうが好まれる
- 試す前にGitHubに連絡する
- 影響を検討する
- 責任ある開示か？と聞かれた
- パブリックなdisclosureである
結論
- セキュリティ研究者として社会に対して義務があると思う
- 多くの開発者はDEFCONやCODE BLUEのセッションを見ていない
- GitHubの調査では500人の開発者に対して1人しかセキュリティリサーチャーはいない
- 脆弱性を修正するいい言葉
  - 直すことができる、テクノロジーがある
- CodeQLを学びOpenRewriteにコントリビュートしてください
- Open Source Security Foundationに参加して